DXL Attribute: How to pass variable between invocations of script?

Mathias Mamsch - Fri Jan 21 11:27:06 EST 2011
Yes you can do this, but there is a problem. You need to ensure, that the data is still valid on the subsequent calls to the calculation, and the even bigger problem is changing the cached data in subsequent calls to dxl programs.

A little background on DOORS memory management: Each DXL program (yes even each attribute dxl or layout dxl calculation) lives in its own DXL context. The DXL context has a list of allocated variables (e.g. if your DXL script allocates a buffer, the memory consumed by it will be associated to the DXL context). If the DXL program ends, then all memory will be released, that is every string declared, every literal of your program, everything. So normally every precached value of another script will be lost during the next script running.

There are two ways to end a program and keep the memory alive: a) 'show' a GUI b) define a dynamic trigger. A dynamic trigger bound to a module, will release its memory when the module closes (which is probably what you want) or when the trigger is deleted, so by defining for example an 'pre close' trigger in the program that does the calculations you can make sure that the memory will stay alive. The next question is how to pass the memory to another program. For this you need to store the memory address somewhere, where the other program can access it. I changed the name of the dynamic trigger (using a bad hack) to contain the memory adress of the data, which is neat, because this also allows you to identify the trigger (to delete it later from another script).

The next alternative is using the global context with 'evalTop_'. This is much easier then the first approach, but has a couple of drawbacks:

a) You need to define the global variable that stores your data exactly once. The variable will be available until the DOORS client ends.

b) evalTop_ will only be executed after the program calling it ends, so you would need to invoke the global level script from another script (like an "post open module" trigger, but this will again introduce the open-penalty).

So which one shall it be? :-)

Regards, Mathias

llandale - Fri Jan 21 15:46:34 EST 2011

Mathias' response seems beyond the capabilities of a first time poster, although he indeed answered the question well.

I would just have an on-demand script that did the evaluation and then set some string attribute with the results for all objects, and schedule this script to run every night. Make the script available for folks who cannot stand 3 hour old data.

But while I'm thinking about it, let me think out loud and let someone comment about this silly notion.

You could define your Text attrDXL to apply to both Objects and the Module. The DXL itself would get the obj."Absolute Number" and if that value were null, then it would know that it was running at the module context, otherwise it knows its running at the object context.

When running at the Module context, the script would do your very clever evalyuation of the other module, then loop through all objects in this module and calculate the result for that object. All the object results are stored at the module context (very large results).

When running at the Object context, the object would query the Module context, search for this objects' results, and display it. The format for each object may be

identifier tab results eol

It should be the case that the first object to need the attr DXL would try to retrieve the module value, which should initiate its 30 seconds running, but each additional object would just retrieve that value and it would not be re-calculated.

You would need a good string searcher, Regular Expressions will be slow here. I suspect, however, the Buffer 'contains' would work for identifiers.

The following attr DXL, when defined for Objects and Module, proves the concept that the code can determine when its running at the module context. The Module level attr value is "Module null".

// dxlModuleLevel
string    AbsNo = obj."Absolute Number" ""
if (AbsNo == "0")  //
then obj.attrDXLName = "Module 0"
elseif(null AbsNo)      //
then obj.attrDXLName = "Module null"
else obj.attrDXLName = AbsNo

So perhaps your code would look like this:

string AbsNo = obj."Absolute Number" ""
Buffer    bufResults = create()
string    Results
 
if (null AbsNo)
{          // Running at module context
    open the other module
    create your other module data structures
    evaluation the other module
    close the other module
    for o in entire (current Module) do
    {  Res = results for this object o
       bufResults += identifier(o)
       bufResults += "\t"
       bufResults += Res
       bufResults += "\t" charof(1) charof(2) charof(3) \n"  // End of line indicator, searched for below
    }
    Results = tempStringOf(bufResults)
    delete your other module data structures
}    // end module context process
else
{    // object context procesing:
   bufResults = mod.attrDXLName
   int PositionID = contains(bufResults, identifier(obj), 0)
   if (PositionID < 0) no results??
   int PositionRes = PositionID + length(idenifier(obj) +1 // +1 skips the tab
   int PositionEnd = contains(bufResults, charof(1) charof(2) charof(3) "", PositionRes)
   Results = bufResults[PositionRes:PositionEnd-1]
}
obj.attrDXLName = Results
delete(bufResults)

• Louie

piotrwie - Wed Jan 26 06:26:15 EST 2011
Thanks llandale,

please see my reply to Mathias - I thought it would appear at the bottom, so it was addressed to both of you.

Piotr

piotrwie - Wed Jan 26 06:24:57 EST 2011
Hello Mathias, llandale

Thank you very much for your emails.
I think I'll experiment with all approaches you're describing. I've still got some time (2 months?) to evaluate which one suits our solution better.

P.S.

I'm not a novice in scripted data processing, nor programming, but I'm more and more amazed how deep is the DOORS knowledge among people on this forum, and how almost non-existing is the actual (official) documentation on it...
I'll try to do it first using shared memory (according to guidelines from Mathias) - this is the fastest solution here. I want simply to share a large single skiplist and allow all dxlAttributes to perform lookups according to its contents.

The data unfortunately must be updated frequently...

Regards,
Piotr